Summary

Fixes #4965 (supersedes #7415)

When response.content raises an exception during stream reading (e.g., ConnectionError, ChunkedEncodingError), subsequent accesses would silently return an empty bytestring or raise a generic RuntimeError instead of re-raising the original error.

This is especially problematic in debuggers where properties may be accessed multiple times — the original error is silently lost, making debugging very difficult.

Root Cause

In the content property:

1. First access enters if self._content is False, calls iter_content()
2. If iter_content() raises (e.g., connection reset mid-stream), the exception propagates
3. But _content_consumed was already set to True inside iter_content()
4. On second access: _content is False is still True, but now hits the _content_consumed guard → raises generic RuntimeError
5. Or if the error happened after partial read, _content may be set to incomplete data

Changes

• Add _content_error attribute to cache the first read exception
• Check _content_error before the _content is False block (addresses reviewer feedback on Fix: retain stream read error on subsequent response.content access #7415)
• Wrap content reading in try/except to capture and store the exception
• Re-raise the same exception object on subsequent accesses (preserves traceback)

Testing

Two new regression tests in test_lowlevel.py:

1. test_response_content_retains_error: Full read failure → second access raises same ConnectionError
2. test_response_content_retains_error_after_partial_read: Partial read then failure → second access raises same ChunkedEncodingError

Both tests verify that the exception type and identity are preserved across multiple accesses.

Difference from #7415

• Initializes _content_error in __init__ (not dynamically in property)
• Checks _content_error before the if _content is False guard (prevents unnecessary re-read attempt)
• Covers both full-failure and partial-read-failure scenarios with tests